The Resource Reservation Protocol (RSVP) is a Multiprotocol Label Switch (MPLS) technology. The RSVP includes a set of messages, objects, and related processing.
In the RSVP, resource reservation is requested for a single flow. During resource reservation, an upstream router requests a downstream router to reserve resources by sending a message, and the downstream router confirms that resource reservation succeeds by sending a message. Usually, the upstream router requests the downstream router to reserve resources by sending a Path message, and the downstream router confirms that resource reservation succeeds by sending a resource reservation (Resv) message.
Generally speaking, a resource reservation request of the RSVP includes a flow descriptor, which is usually represented by a (FLOWSPEC, FILTER_SPEC) pair. The FLOWSPEC indicates quality of service (QoS) to be satisfied, so as to perform packet scheduling at a node. The FILTER_SPEC is adapted to classify received data packets according to the QoS.
A bandwidth reservation method is provided in the conventional solution. In the method, a label switched path (LSP) is created and bandwidth reservation is requested through a Path message of the RSVP Traffic Engineering (TE) Protocol, which is specifically implemented as follows. A source node sends a Path message to request a target node to reserve bandwidth. A desired bandwidth value to be reserved is usually set in a SENDER_TESPEC object in the Path message. The target node reserves bandwidth for the source node according to the SENDER_TESPEC object, carries a reserved bandwidth value in a FLOWSPEC object in the Resv message, and sends the Resv message to the source node to indicate that the resource reservation succeeds. The FLOWSPEC object of the RSVP TE Protocol inherits the FLOWSPEC object of the RSVP protocol, which is specifically shown in FIG. 1. In the RSVP TE, a Token Bucket Rate field is usually adopted to represent resource reservation information, and a unit of the field is byte and a type thereof is float.
During the development of the present invention, the inventors find that the conventional solution at least has the following problems.
1. In the conventional solution, a data type of reserved bandwidth is configured to be an integer type, and the reserved bandwidth usually occupies 32 bits. However, during transmission in the conventional solution, the configured reserved bandwidth needs to be converted into a float type. At this time, for the reserved bandwidth represented by the float type, accuracy loss may occur due to an insufficient bit length, resulting in inaccurate bandwidth reservation of the target node.
2. As forwarding capability of an existing mainstream core router is up to a Gbps or Tbps magnitude, overflow occurs when a bandwidth with a Gbps or Tbps magnitude occupies 32 bits in the conventional solution, also resulting in inaccurate bandwidth reservation of the target node.